fix: centralize operation error handling by wa0x6e · Pull Request #1071 · snapshot-labs/snapshot-hub

wa0x6e · 2026-02-14T20:56:19Z

This PR refactors the operations/ files, and centralize the error handling in a single place, for easier filtering out of some error code (and also simplify the code)

Summary

Centralized error handling for all graphql resolvers via a withErrorHandler wrapper in src/graphql/operations/index.ts
All resolver errors are caught, logged, and returned as Promise.reject(new Error('request failed')) — no errors bubble up
ER_QUERY_TIMEOUT errors are filtered out from Sentry via IGNORED_ERROR_CODES constant (still logged)
Removed redundant try/catch blocks and unused capture/log imports from 12 graphql operation files

Test plan

Verify queries still return correct results

Trigger a query timeout using the query from the Sentry issue and confirm it is logged but NOT reported to Sentry:

query {
  votes(first: 10, skip: 46, orderBy: "created", orderDirection: desc) {
    proposal {
      space {
        delegationPortal {
          delegationType
          delegationContract
          delegationNetwork
          delegationApi
        }
      }
    }
  }
}

Verify other errors (DB, JSON.parse, formatting) are still captured in Sentry
Verify all resolvers return 'request failed' on error, no raw errors bubble up

Fixes SNAPSHOT-HUB-35 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Copilot

Pull request overview

This PR centralizes MySQL queryAsync error handling in src/helpers/mysql.ts and removes per-resolver try/catch blocks (and related logging/Sentry imports) from several GraphQL operation resolvers to reduce duplication.

Changes:

Override Pool.prototype.queryAsync to catch MySQL query errors, log them, optionally report to Sentry, and rethrow a generic "request failed" error.
Adjust Bluebird promisifyAll to skip promisifying query so the custom queryAsync can be used.
Remove redundant try/catch + capture/log imports from multiple GraphQL operation resolvers.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/helpers/mysql.ts	Centralizes `queryAsync` behavior (custom implementation + Sentry/logging) and alters Bluebird promisification behavior.
src/graphql/operations/votes.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/users.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/subscriptions.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/statements.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/statement.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/roles.ts	Removes local try/catch and Sentry/log handling around DB query + mapping.
src/graphql/operations/proposals.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/proposal.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/messages.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/leaderboards.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/follows.ts	Removes local try/catch and Sentry/log handling around DB queries.
src/graphql/operations/aliases.ts	Removes local try/catch and Sentry/log handling around DB queries.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 5 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-14T21:26:35Z

+function withErrorHandler(fn) {
+  return (...args) =>
+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);
+      log.error(`[graphql] ${JSON.stringify(e)}`);
+      return Promise.reject(new Error('request failed'));
+    });
+}


The withErrorHandler wrapper calls .catch() on all wrapped functions, but some operations (plugins, skins, validations, strategies) are synchronous and return values directly instead of Promises. Calling .catch() on a non-Promise value will cause a runtime error.

To fix this, the wrapper should handle both synchronous and asynchronous functions. Consider wrapping the function call in Promise.resolve() first, or check if the return value is a Promise before calling .catch().

Copilot · 2026-02-14T21:26:35Z

 };
+
+export default Object.fromEntries(
+  Object.entries(operations).map(([key, fn]) => [key, withErrorHandler(fn)])


The operations space.ts, spaces.ts, ranking.ts, and vote.ts still have their own try/catch blocks with error handling and logging. This means errors in these operations will be logged twice - once in their own try/catch and again in the withErrorHandler wrapper. Additionally, these operations return Error objects (not Promise.reject), which won't trigger the .catch() in the wrapper, so the centralized error handling won't apply to them at all.

Either remove the try/catch blocks from these files to use only the centralized handler, or remove them from the operations object so they aren't wrapped. If these operations need special error handling (like PublicError), that logic should be incorporated into the centralized handler or kept separate from the wrapper.

Suggested change

Object.entries(operations).map(([key, fn]) => [key, withErrorHandler(fn)])

Object.entries(operations).map(([key, fn]) => {

const skipWrapper = ['space', 'spaces', 'ranking', 'vote'];

return skipWrapper.includes(key) ? [key, fn] : [key, withErrorHandler(fn)];

})

Copilot · 2026-02-14T21:26:35Z

+function withErrorHandler(fn) {
+  return (...args) =>
+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);


The centralized error handler no longer captures context information (args, context, info) that was previously passed to capture() in the individual resolvers. This context is valuable for debugging and error tracking in Sentry. The wrapper has access to the arguments passed to each resolver function through the ...args parameter, but these aren't being passed to capture().

Consider capturing the arguments in the error handler to preserve this debugging context.

Suggested change

if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);

if (!IGNORED_ERROR_CODES.includes(e.code)) {

const [, resolverArgs, context, info] = args;

capture(e, { args: resolverArgs, context, info });

}

this make sense as well. maybe we need them?

Copilot · 2026-02-14T21:26:35Z

+  return (...args) =>
+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);
+      log.error(`[graphql] ${JSON.stringify(e)}`);


The centralized error logging no longer includes the specific operation name that failed. Previously, each operation logged errors with a specific identifier like [graphql] votes, [graphql] proposals, etc. Now all errors are logged as just [graphql], making it harder to identify which operation failed without examining the full error object.

Consider including the operation name in the log message by adding it as a parameter to the wrapper or extracting it from the function name.

ChaituVR · 2026-02-16T10:40:00Z

-    } catch (e: any) {
-      capture(e, { args, context, info });
-      log.error(`[graphql] votes, ${JSON.stringify(e)}`);
-      return Promise.reject(new Error('request failed'));
-    }


Can remove catch on vote.ts also right?

Also on vp.ts it will ignore the promise.reject messages and will always return request failed?

vote.ts — try/catch with capture
space.ts — try/catch with PublicError handling
spaces.ts — try/catch with PublicError handling
ranking.ts — try/catch with PublicError handling
options.ts — internal run loop with try/catch

ChaituVR · 2026-02-16T10:45:09Z

+  return (...args) =>
+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);
+      log.error(`[graphql] ${JSON.stringify(e)}`);


Before we know which operation is failing, copilot is correct here

ChaituVR · 2026-02-16T10:45:11Z

+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);
+      log.error(`[graphql] ${JSON.stringify(e)}`);
+      return Promise.reject(new Error('request failed'));


Maybe need to figure out how we should handle custom error messages, for example vp.ts, user.ts

ChaituVR · 2026-02-16T10:47:05Z

+function withErrorHandler(fn) {
+  return (...args) =>
+    fn(...args).catch(e => {
+      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);


this make sense as well. maybe we need them?

wa0x6e and others added 2 commits February 14, 2026 15:55

fix: centralize queryAsync error handling in mysql helper

e06bbf3

Fixes SNAPSHOT-HUB-35 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

fix: filter out ER_QUERY_TIMEOUT errors from Sentry

d438e0e

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

wa0x6e requested a review from Copilot February 14, 2026 21:00

Copilot started reviewing on behalf of wa0x6e February 14, 2026 21:01 View session

Copilot AI reviewed Feb 14, 2026

View reviewed changes

Comment thread src/helpers/mysql.ts Outdated

Comment thread src/helpers/mysql.ts Outdated

Comment thread src/graphql/operations/roles.ts

wa0x6e and others added 4 commits February 14, 2026 16:15

fix: wrap all graphql resolvers to reject on any error

f16f54d

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

refactor: move error handling from mysql.ts to resolver wrapper

846466e

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

refactor: rename safe to withErrorHandler

4f24b7f

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

refactor: extract ignored error codes to constant

1396047

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

wa0x6e requested a review from Copilot February 14, 2026 21:22

Copilot started reviewing on behalf of wa0x6e February 14, 2026 21:22 View session

wa0x6e changed the title ~~fix: centralize queryAsync error handling in mysql helper~~ fix: centralize operation error handling Feb 14, 2026

Copilot AI reviewed Feb 14, 2026

View reviewed changes

wa0x6e requested a review from ChaituVR February 14, 2026 21:34

ChaituVR suggested changes Feb 16, 2026

View reviewed changes

-  Object.entries(operations).map(([key, fn]) => [key, withErrorHandler(fn)])
+  Object.entries(operations).map(([key, fn]) => {
+    const skipWrapper = ['space', 'spaces', 'ranking', 'vote'];
+    return skipWrapper.includes(key) ? [key, fn] : [key, withErrorHandler(fn)];
+  })

-      if (!IGNORED_ERROR_CODES.includes(e.code)) capture(e);
+      if (!IGNORED_ERROR_CODES.includes(e.code)) {
+        const [, resolverArgs, context, info] = args;
+        capture(e, { args: resolverArgs, context, info });
+      }

Uh oh!

Conversation

wa0x6e commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related

Test plan

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

ChaituVR Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

wa0x6e commented Feb 14, 2026 •

edited

Loading